Hallo zusammen. In der ersten Aufgabe solltet ihr REST-TrueWeb-Service implementieren. In

diesem Video zeige ich euch, wie das mit der JuxRES API von Java funktioniert.

REST Web Services verwenden HTTP als Protokoll zwischen Client und Server. Die JuxRES API

bietet euch daher Schnittstellen, um HTTP-Requests auf Client-Seite zu bauen. Auf Serverseite

benötigt man natürlich etwas mehr als nur HTTP-Anfragen. Praktischerweise wird der

Web-Service selbst in JuxRES als ganz normale Java-Anwendung implementiert und diese dann

über einen Java-internen Web-Server nach außen zur Verfügung gestellt.

Die genaue Form der Bereitstellung wird dabei mittels Annotationen gekennzeichnet. Mit Annotationen

kann man Java-Methoden sowohl einen URI-Pfad zuordnen, als auch die HTTP-Operation angeben,

die zu dieser Methode führen soll. Wie das genau aussieht, schauen wir uns im Laufe des

Videos an verschiedenen Beispielen an. Nach dem Importieren der Java-Dateien legt JuxRES

im Package javax.ws.rs. Neben JuxRES verwenden wir noch das Framework Jersey. Nachdem JuxRES

nur eine Spezifikation ist, ist Jersey eine Implementierung davon. Es gibt hier verschiedene

Web-Service-Implementierungen. In der Übung verwenden wir Grizzly. Die Packages für Jersey

und Grizzly sind unter org.glassflush.jersey. Für weitere Informationen schaut euch auch

gerne die Projektseite von Jersey an. Im Preufeilzeichnis findet ihr natürlich alle benötigten Java-Dateien

für diese Bibliotheken. Wir hangen uns jetzt am Beispiel einer Q-Anwendung

durch verschiedene JuxRES-Konzepte durch, die ihr im Laufe der Aufgabe benötigen werdet.

Wir betrachten jeweils die Server und die Client-Seite.

Beginnen wir mit dem Grundgerüst. Auf Server-Seite ist unser Web-Service als ganz normale Klasse

implementiert. Die Annotation addPath bestimmt dabei den Grundfahrt unseres Dienstes, in

dem Fall Q. Die Annotation singleton verhindert, dass bei jedem Aufruf an den Web-Service eine

neue Instanz der Klasse erzeugt wird. Den Server selbst starten wir in der Main.

Wir zeugen zuerst die URI, unter der der Server läuft. Die in unserem Beispiel verwendete

URI, Ecke geklammert, Doppelpunkt, Doppelpunkt, Ecke geklammert zu, ist eine Wildcard-Adresse.

Dadurch nimmt der Server alle Verbindungen sowohl über IPv4 als auch über IPv6 an.

Der Port, auf dem der Server hocht, wird auch über die URI definiert.

Mit der Resource-Config bestimmen wir das Verhalten unseres Grizzly-Servers. Hier übergeben wir

unsere Server-Klasse in unserem Beispiel mwq-server.class. Mit der URI und der Config wird der Server

dann mit der Methode createHttpServer erstellt. Auf Client-Seite brauchen wir natürlich ebenfalls

die URI des Servers. Localhost eignet sich zum Testen, wenn man Client und Server auf

demselben Rechner startet. In eurer fertigen Abgabe sollen Client und Server aber natürlich

auf unterschiedlichen Rechner laufen. Euer tatsächlicher Jux.js-Client, der mit dem

Server kommuniziert, ist ein Web-Target, das ihr mit dem Client-Bilder erzeugt. Mit der

Target-Methode setzt ihr dabei die Ziel-URI des Servers. Mit path den Grundpfad eures Web-Services,

den ihr mit der Annotation at path definiert habt. Also in unserem Fall wieder Q.

Um irgendeine Funktionalität zur Verfügung zu stellen, braucht unser Web-Service natürlich

Methoden, die ihr dem Client anbieten kann. Serverseitig werden diese Methoden als ganz

normale Public-Java-Methoden implementiert. Mit welcher HTTP-Operation auf die Methode

zugegriffen wird, kann wieder mit einer Annotation festgelegt werden. Da ihr in eurem Web-Service

wahrscheinlich mehr als vier Methoden wollt, kann zudem der Unterpfad angegeben werden,

unter dem die Methode läuft. Dabei wird immer vom Grundpfad eures Web-Services ausgegangen.

Im Beispiel liegt die Methode getSize, also unter dem Pfad Q slash size.

Die Antwort an den Client ist dabei ein Response-Objekt, in dem der Antwort-Code auch direkt codiert

wird. Im Beispiel kann die Methode nicht viel schlagen, wir geben also standardmäßig den

Code 200 ok, zusammen mit der Größe der Q zurück.

Jetzt zur kleinen Seite. Auf die Methode unseres Web-Services greifen wir mit dem vorher angelegten

Web-Target zu. Auch hier muss natürlich wieder der Pfad unserer Methode angegeben werden.

Den Grundpfad haben wir bereits beim Erstellen des Web-Targets definiert.

Dann muss die jeweilige HTTP-Operation ausgewählt werden. Hier im Beispiel get.